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Abstract 


Resource Reservation Protocol (RSVP) association signaling can be 
used to bind two unidirectional Label Switched Paths (LSPs) into an 
associated bidirectional LSP. When an associated bidirectional LSP 
is co-routed, the reverse LSP follows the same path as its forward 
LSP. This document updates the fast reroute procedures defined in 
RFC 4090 to support both single-sided and double-sided provisioned 
associated bidirectional LSPs. This document also updates the 
procedure for associating two reverse LSPs defined in RFC 7551 to 
support co-routed bidirectional LSPs. The fast reroute procedures 
can ensure that, for the co-routed LSPs, traffic flows on co-routed 
paths in the forward and reverse directions after a failure event. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8537. 
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1. Introduction 


The Resource Reservation Protocol (RSVP) (Extended) ASSOCIATION 
Object is specified in [RFC6780] and can be used generically to 
associate Multiprotocol Label Switching (MPLS) and Generalized MPLS 
(GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs). 
[RFC7551] defines mechanisms for binding two point-to-point (P2P) 
unidirectional LSPs [RFC3209] into an associated bidirectional LSP. 
There are two models described in [RFC7551] for provisioning an 
associated bidirectional LSP: single-sided and double-sided. In both 
models, the reverse LSP of the bidirectional LSP may or may not be 
co-routed and follow the same path as its forward LSP. 


In some packet transport networks, there are requirements where the 
reverse LSP of a bidirectional LSP needs to follow the same path as 
its forward LSP [RFC6373]. The MPLS Transport Profile (MPLS-TP) 
[RFC6370] architecture facilitates the co-routed bidirectional LSP by 
using GMPLS extensions [RFC3473] to achieve congruent paths. 

However, RSVP association signaling allows enabling co-routed 
bidirectional LSPs without having to deploy GMPLS extensions in the 


existing networks. The association signaling also allows taking 
advantage of the existing TE and fast reroute mechanisms in the 
network. 


[RFC4090] defines fast reroute extensions for RSVP-TE LSPs, which are 
also applicable to the associated bidirectional LSPs. [RFC8271 
defines fast reroute procedures for GMPLS signaled bidirectional LSPs 
such as coordinating bypass tunnel assignments in the forward and 


reverse directions of the LSP. The mechanisms defined in [RFC8271] 
are also useful for the fast reroute of associated bidirectional 
LSPs. 


This document updates the fast reroute procedures defined in 
[RFC4090] to support both single-sided and double-sided provisioned 
associated bidirectional LSPs. This document also updates the 
procedure for associating two reverse LSPs defined in [RFC7551] to 
support co-routed bidirectional LSPs. The fast reroute procedures 
can ensure that for the co-routed LSPs, traffic flows on co-routed 
paths in the forward and reverse directions after fast reroute. 
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Assumptions and Considerations 
The following assumptions and considerations apply to this document: 


o The fast reroute procedure for the unidirectional LSPs is defined 
in [RFC4090] and is not modified by this document. 


o The fast reroute procedure when using unidirectional bypass 
tunnels is defined in [RFC4090] and is not modified by this 
document. 


o This document assumes that the fast reroute bypass tunnels used 
for protected associated bidirectional LSPs are also associated 
bidirectional. 


o This document assumes that the fast reroute bypass tunnels used 
for protected co-routed associated bidirectional LSPs are also co- 
routed associated bidirectional. 


o The fast reroute procedure to coordinate the bypass tunnel 
assignment defined in this document may be used for protected 
associated bidirectional LSPs that are not co-routed but requires 
that the downstream Point of Local Repair (PLR) and Merge Point 
(MP) pair of the forward LSP matches the upstream MP and PLR pair 
of the reverse LSP. 


o Unless otherwise specified in this document, the fast reroute 
procedures defined in [RFC4090] are used for associated 
bidirectional LSPs. 


Conventions Used in This Document 
Key Word Definitions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


Terminology 


The reader is assumed to be familiar with the terminology defined in 
[RFC2205], [RFC3209], [RFC4090], [RFC7551], and [RFC8271]. 
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2.2.1. Forward Unidirectional LSPs 


Two reverse unidirectional P2P LSPs are set up in opposite directions 
between a pair of source and destination nodes to form an associated 
bidirectional LSP. In the case of single-sided provisioned LSP, the 
originating LSP with a REVERSE_LSP Object [RFC7551] is identified as 
a forward unidirectional LSP. In the case of double-sided 
provisioned LSP, the LSP originating from the higher node address (as 
source) and terminating on the lower node address (as destination) is 
identified as a forward unidirectional LSP. 


2.2.2. Reverse Co-routed Unidirectional LSPs 


Two reverse unidirectional P2P LSPs are set up in opposite directions 
between a pair of source and destination nodes to form an associated 
bidirectional LSP. A reverse unidirectional LSP originates on the 
same node where the forward unidirectional LSP terminates, and it 
terminates on the same node where the forward unidirectional LSP 
originates. A reverse co-routed unidirectional LSP traverses along 
the same path as the forward-direction unidirectional LSP in the 
opposite direction. 


3. Problem Statement 


As specified in [RFC7551], in the single-sided provisioning case, the 
RSVP-TE tunnel is configured only on one endpoint node of the 
bidirectional LSP. An LSP for this tunnel is initiated by the 
originating endpoint with the (Extended) ASSOCIATION Object 
containing Association Type set to "Single-Sided Associated 
Bidirectional LSP" and the REVERSE_LSP Object inserted in the RSVP 
Path message. The remote endpoint then creates the corresponding 
reverse TE tunnel and signals the reverse LSP in response using the 
information from the REVERSE_LSP Object and other objects present in 
the received RSVP Path message. As specified in [RFC7551], in the 
double-sided provisioning case, the RSVP-TE tunnel is configured on 
both endpoint nodes of the bidirectional LSP. Both forward and 
reverse LSPs are initiated independently by the two endpoints with 
the (Extended) ASSOCIATION Object containing Association Type set to 


"Double-Sided Associated Bidirectional LSP". With both single-sided 
and double-sided provisioned bidirectional LSPs, the reverse LSP may 
or may not be congruent (i.e., co-routed) and follow the same path as 


its forward LSP. 


Both single-sided and double-sided associated bidirectional LSPs 
require solutions to the following issues for fast reroute to ensure 
co-routing after a failure event. 
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3.1. Fast Reroute Bypass Tunnel Assignment 


In order to ensure that the traffic flows on a co-routed path after a 
link or node failure on the protected co-routed LSP path, the 
midpoint PLR nodes need to assign matching bidirectional bypass 
tunnels for fast reroute. Such bypass assignment requires 
coordination between the PLR nodes in both the forward and reverse 
directions when more than one bypass tunnel is present on a PLR node. 


«-- Bypass N --> 


4R----- + +----- + 
| H  +--------- + I | 
+--+--+ +--+--+ 
| | 
LSP1 --» | LSP1 --» | LSP1 --» LSP1 --» 
4R----- + +--+--+ +--+--+ 4R----- + +----- + 
A 4+-------- + B 4+----X----+ Q 4-------- +. oD) o Re + E 
+----- + +--+--+ +--+--+ +----- + +----- + 
«-- LSP2 | <-- LSP2 | «-- LSP2 «-- LSP2 
| | 
| | 
+--+--+ +--+--+ 
| F +--------- + G | 
+----- + +----- + 


<-- Bypass S --> 


Figure 1: Multiple Bidirectional Bypass Tunnels 


As shown in Figure 1, there are two bypass tunnels available: bypass 
tunnel N (on path B-H-I-C) and bypass tunnel S (on path B-F-G-C). 

The midpoint PLR nodes B and C need to coordinate bypass tunnel 
assignment to ensure that traffic in both directions flows through 
either bypass tunnel N or bypass tunnel S after the link B-C failure. 


3.2. Node Protection Bypass Tunnels 


When using a node protection bypass tunnel with a protected 
associated bidirectional LSP, after a link failure, the forward and 
reverse LSP traffic can flow on different node protection bypass 
tunnels in the upstream and downstream directions. 
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<-- Bypass N --> 


4----- * 4----- + 
| H  +------------------------ + I | 
+--+--+ +--+--+ 


| LSP1 --» LSP1 --» | LSP1 --» LSP1 --» 
+--+--+ +----- + +--+--+ +----- + +----- + 
| A +-------- + B -4----X----* C +-------- + D +-------- + E 
+----- + +--+--+ 4R----- + +--+--+ +----- + 
«-- LSP2 | «-- LSP2 «-- LSP2 | «-- LSP2 


| Rerouted-LSP1 --> | 


+--+--+ +--+--+ 
| FE +------------------------ + G | 
+----- + +----- + 


<-- Bypass S --> 
Figure 2: Node Protection Bypass Tunnels 


As shown in Figure 2, after the link B-C failure, the downstream PLR 
node B reroutes the protected forward LSP1 traffic over bypass tunnel 
S (on path B-F-G-D) to reach downstream MP node D, whereas the 
upstream PLR node C reroutes the protected reverse LSP2 traffic over 
bypass tunnel N (on path C-I-H-A) to reach the upstream MP node A. 

As a result, the traffic in the forward and reverse directions flows 
on different bypass tunnels, which can cause the co-routed associated 
bidirectional LSP to be no longer co-routed. However, unlike GMPLS 
LSPs, the asymmetry of paths in the forward and reverse directions 
does not result in RSVP soft-state timeout with the associated 
bidirectional LSPs. 


3.3. Bidirectional LSP Association at Midpoints 


In packet transport networks, a restoration LSP is signaled after a 
link failure on the protected LSP path, and the protected LSP may or 
may not be torn down [RFC8131]. In this case, multiple forward and 
reverse LSPs of a co-routed associated bidirectional LSP may be 
present at midpoint nodes with identical (Extended) ASSOCIATION 
Objects. This creates an ambiguity at midpoint nodes to identify the 
correct associated LSP pair for fast reroute bypass assignment (e.g., 
during the recovery phase of the RSVP graceful restart procedure). 
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LSP3 --» LSP3 --» LSP3 --» 
LSP1 --» LSP1 --» LSP1 --» LSP1 --» 
4R----- + +----- + +----- + 4R----- + +----- + 
A 4+-------- + B 4+----X----+ Q *-------- + D c*-------- * E 
4R----- + +--+--+ +--+--+ +----- + +----- + 
<-- LSP2 | <-- LSP2 | «-- LSP2 «-- LSP2 
«-- LSP4 | | | «-- LSP4 «-- LSP4 
| | 
|  LSP3 --» | 
+--+--+ +--+--+ 
| F +--------- + G | 
+----- + +----- + 
«-- Bypass S --> 
«-- LSP4 


Figure 3: Restoration LSP Setup after Link Failure 


As shown in Figure 3, the protected LSPs (LSP1 and LSP2) are an 
associated LSP pair; similarly, the restoration LSPs (LSP3 and LSP4) 
are an associated LSP pair. Both pairs belong to the same associated 
bidirectional LSP and carry identical (Extended) ASSOCIATION Objects. 
In this example, the midpoint node D may mistakenly associate LSP1 
with the reverse LSP4 instead of the reverse LSP2 due to the matching 
(Extended) ASSOCIATION Objects. This may cause the co-routed 
associated bidirectional LSP to be no longer co-routed after fast 
reroute. Since the bypass assignment needs to be coordinated between 
the forward and reverse LSPs, this can also lead to undesired bypass 
tunnel assignments. 


4. Signaling Procedure 


4.1. Associated Bidirectional LSP Fast Reroute 


For both single-sided and double-sided associated bidirectional LSPs, 
the fast reroute procedure specified in [RFC4090] is used. In 
addition, the mechanisms defined in [RFC8271] are used as follows: 


o The BYPASS ASSIGNMENT IPv4 subobject (value 38) and IPv6 subobject 
(value 39) defined in [RFC8271] are used to coordinate bypass 
tunnel assignment between the PLR nodes in both the forward and 
reverse directions (see Figure 1). The BYPASS ASSIGNMENT and 
Node-ID address [RFC4561] subobjects MUST be added by the 
downstream PLR node in the RECORD ROUTE Object (RRO) of the RSVP 
Path message of the forward LSP to indicate the local bypass 
tunnel assignment using the procedure defined in [RFC8271]. The 
upstream node uses the bypass assignment information (namely, 
bypass tunnel source address, destination address, and Tunnel ID) 
in the received RSVP Path message of the protected forward LSP to 
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find the associated bypass tunnel in the reverse direction. The 
upstream PLR node MUST NOT add the BYPASS ASSIGNMENT subobject in 
the RRO of the RSVP Path message of the reverse LSP. 


o The downstream PLR node initiates the bypass tunnel assignment for 
the forward LSP. The upstream PLR (forward-direction LSP MP) node 
reflects the associated bypass tunnel assignment for the reverse- 
direction LSP. The upstream PLR node MUST NOT initiate the bypass 
tunnel assignment. 


o If the indicated forward bypass tunnel or the associated reverse 
bypass tunnel is not found, the upstream PLR SHOULD send a Notify 
message [RFC3473] with Error Code "FRR Bypass Assignment Error" 
(value 44) and Sub-code "Bypass Tunnel Not Found" (value 1) 

RFC8271] to the downstream PLR. 


o If the bypass tunnel cannot be used as described in Section 4.5.3 
of [RFC8271], the upstream PLR SHOULD send a Notify message 
RFC3473] with Error Code "FRR Bypass Assignment Error" (value 44) 
and Sub-code "Bypass Assignment Cannot Be Used" (value 0) 

RFC8271] to the downstream PLR. 


o After a link or node failure, the PLR nodes in both forward and 
reverse directions trigger fast reroute independently using the 
procedures defined in [RFC4090] and send the forward and protected 
reverse LSP modified RSVP Path messages and traffic over the 
bypass tunnel. The RSVP Resv signaling of the protected forward 
and reverse LSPs follows the same procedure as defined in 
[RFC4090] and is not modified by this document. 


4.1.1. Restoring Co-routing with Node Protection Bypass Tunnels 


After fast reroute, the downstream MP node assumes the role of 
upstream PLR and reroutes the reverse LSP RSVP Path messages and 
traffic over the bypass tunnel on which the forward LSP RSVP Path 
messages and traffic are received. This procedure is defined as 
"restoring co-routing" in [RFC8271]. This procedure is used to 
ensure that both forward and reverse LSP signaling and traffic flow 
on the same bidirectional bypass tunnel after fast reroute. 


As shown in Figure 2, when using a node protection bypass tunnel with 
protected co-routed LSPs, asymmetry of paths can occur in the forward 
and reverse directions after a link failure [RFC8271]. In order to 
restore co-routing, the downstream MP node D (acting as an upstream 
PLR) MUST trigger the procedure to restore co-routing and reroute the 
protected reverse LSP2 RSVP Path messages and traffic over the bypass 
tunnel S (on path D-G-F-B) to the upstream MP node B upon receiving 
the protected forward LSP modified RSVP Path messages and traffic 
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over the bypass tunnel S (on path D-G-F-B) from node B. The upstream 
PLR node C stops receiving the RSVP Path messages and traffic for the 
reverse LSP2 from node D (resulting in RSVP soft-state timeout), and 
it stops sending the RSVP Path messages for the reverse LSP2 over the 
bypass tunnel N (on path C-I-H-A) to node A. 


4.1.2. Unidirectional Link Failures 


The unidirectional link failures can cause co-routed associated 
bidirectional LSPs to be no longer co-routed after fast reroute with 
both link protection and node protection bypass tunnels. However, 
the unidirectional link failures in the upstream and/or downstream 
directions do not result in RSVP soft-state timeout with the 
associated bidirectional LSPs as upstream and downstream PLRs trigger 
fast reroute independently. The asymmetry of forward and reverse LSP 
paths due to the unidirectional link failure in the downstream 
direction can be corrected by using the procedure to restore co- 
routing specified in Section 4.1.1. 


4.1.3.  Revertive Behavior after Fast Reroute 


When the revertive behavior is desired for a protected LSP after the 
link is restored, the procedure defined in Section 6.5.2 of [RFC4090] 
is followed. 


o The downstream PLR node starts sending the RSVP Path messages and 
traffic flow of the protected forward LSP over the restored link 
and stops sending them over the bypass tunnel [RFC4090]. 


o The upstream PLR node (when the protected LSP is present) also 
Starts sending the RSVP Path messages and traffic flow of the 
protected reverse LSPs over the restored link and stops sending 
them over the bypass tunnel [RFC4090]. 


o For node protection bypass tunnels (see Figure 2), after restoring 
co-routing, the upstream PLR node D SHOULD start sending RSVP Path 
messages and traffic for the reverse LSP over the original link 
(C-D) when it receives the unmodified RSVP Path messages and 
traffic for the protected forward LSP over it and stops sending 
them over the bypass tunnel S (on path D-G-F-B). 


4.1.4. Bypass Tunnel Provisioning 


Fast reroute bidirectional bypass tunnels can be single-sided or 
double-sided associated tunnels. For both single-sided and double- 
Sided associated bypass tunnels, the fast reroute assignment policies 
need to be configured on the downstream PLR nodes of the protected 
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LSPs that initiate the bypass tunnel assignments. For single-sided 
associated bypass tunnels, these nodes are the originating endpoints 
of their signaling. 


4.1.5. One-to-One Bypass Tunnel 


The fast reroute signaling procedure defined in this document can be 
used for both facility backup described in Section 3.2 of [RFC4090] 
and one-to-one backup described in Section 3.1 of [RFC4090]. As 
described in Section 4.5.2 of [RFC8271], in the one-to-one backup 
method, if the associated bidirectional bypass tunnel is already in 
use at the upstream PLR, it SHOULD send a Notify message [RFC3473] 
with Error Code "FRR Bypass Assignment Error" (value 44) and Sub-code 
"One-to-One Bypass Already in Use" (value 2) to the downstream PLR. 


4.2. Bidirectional LSP Association at Midpoints 


In order to associate the LSPs unambiguously at a midpoint node (see 
Figure 3), the endpoint node MUST signal the Extended ASSOCIATION 
Object and add a unique Extended Association ID for each associated 
forward and reverse LSP pair forming the bidirectional LSP. An 
endpoint node MAY set the Extended Association ID to the value 
formatted according to the structure shown in Appendix A. 


o For single-sided provisioned bidirectional LSPs [RFC7551], the 
originating endpoint signals the Extended ASSOCIATION Object with 
a unique Extended Association ID. The remote endpoint copies the 
contents of the received Extended ASSOCIATION Object including the 
Extended Association ID in the RSVP Path message of the reverse 
LSP's Extended ASSOCIATION Object. 


o For double-sided provisioned bidirectional LSPs [RFC7551], both 
endpoints need to ensure that the bidirectional LSP has a unique 
Extended ASSOCIATION Object for each forward and reverse LSP pair 
by selecting appropriate unique Extended Association IDs signaled 
by them. A controller can be used to provision a unique Extended 


Association ID on both endpoints. The procedure for selecting 
unique Extended Association IDs is outside the scope of this 
document. 


5. Compatibility 


This document updates the procedures for fast reroute for associated 
bidirectional LSPs defined in [RFC4090] and the procedures for 


associating bidirectional LSPs defined in [RFC7551]. The procedures 
use the signaling messages defined in [RFC8271]; no new signaling 
messages are defined in this document. The procedures ensure that 


for the co-routed LSPs, traffic flows on co-routed paths in the 
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8. 


forward and reverse directions after fast reroute. Operators wishing 
to use this function SHOULD ensure that it is supported on all the 
nodes on the LSP path. The nodes not supporting this function can 
cause the traffic to flow on asymmetric paths in the forward and 
reverse directions of the associated bidirectional LSPs after fast 
reroute. 


Security Considerations 


This document updates the signaling mechanisms defined in [RFC4090] 
and [RFC7551]. It does not introduce any additional security 
considerations other than those already covered in [RFC4090], 
[RFC7551], [RFC8271], and the MPLS/GMPLS security framework 
[RFC5920]. 


IANA Considerations 
This document has no IANA actions. 
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Appendix A. Extended Association ID 


The Extended Association ID in the Extended ASSOCIATION Object 
[RFC6780] can be set to the value formatted according to the 
structure shown in the following example to uniquely identify 
associated forward and reverse LSP pairs of an associated 
bidirectional LSP. 


An example of the IPv4 Extended Association ID format is shown below: 
0 1 2 3 
0I 2.9.4 .,506-7-8:9 0.1 2.9 4 576 78 9-0 1 2:3 4.5-6 T 8-9-0- T 

T—R——R-—R———R— —— — —— 4M BB 4-446 
| IPv4 LSP Source Address 

T—R——R-—R———— —— — —— MB BB v4.46 
| Reserved | LSP ID 
T—R——R-—R———— -—— — 4M BB. BM M6 

Variable Length ID 
T—R——R-—R———— -—— — -—R— MB B.M MM MM 9-4 
Figure 4: IPv4 Extended Association ID Format Example 

IPv4 LSP Source Address 
IPv4 source address of the forward LSP [RFC3209]. 

LSP ID 
16-bit LSP ID of the forward LSP [RFC3209]. 


Variable Length ID 


Variable length Extended Association ID [RFC6780] inserted by the 
endpoint node of the associated bidirectional LSP [RFC7551]. 
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An example of the IPv6 Extended Association ID format is shown below: 


0 1 2 3 
Q L-Z 3 4 5 6 7 8-9 0.1] 2 3.4596 785.9 0 7172 345 6 7 8 9.0 1 
C ———————  —— Na 


+ + 
IPv6 LSP Source Address 
+ + 
(16 bytes) 
+ + 


VRBE RR RETE RR] RR 
Reserved | LSP ID 
+-+-+-+-+-+-+-+-+-++ +++ 


Variable Length ID 
E E E ped PE ou E E TE EE E E oed Ete Su 
Figure 5: IPv6 Extended Association ID Format Example 

LSP Source Address 

IPv6 source address of the forward LSP [RFC3209]. 
LSP ID 

16-bit LSP ID of the forward LSP [RFC3209]. 
Variable Length ID 


Variable length Extended Association ID [RFC6780] inserted by the 
endpoint node of the associated bidirectional LSP [RFC7551]. 


In both IPv4 and IPv6 examples, the Reserved flags MUST be set to 0 
on transmission. 
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